Skip to content

NIFI-16002 Fix LookupRecord writing to wrong level when parent path is missing#11333

Open
rakesh-rsky wants to merge 1 commit into
apache:mainfrom
rakesh-rsky:fix/NIFI-16002-lookuprecord-missing-parent
Open

NIFI-16002 Fix LookupRecord writing to wrong level when parent path is missing#11333
rakesh-rsky wants to merge 1 commit into
apache:mainfrom
rakesh-rsky:fix/NIFI-16002-lookuprecord-missing-parent

Conversation

@rakesh-rsky

Copy link
Copy Markdown
Contributor

NIFI-16002 Fix LookupRecord writing to wrong level when parent path is missing

When the configured Result RecordPath contains intermediate nodes that do not yet exist in the record (e.g. /enrichment/value where /enrichment is absent), the RecordPath evaluator returns a missing-child FieldValue with a null value. When updateValue is later called, getParentRecord() skips the null intermediate node and finds the root record instead, writing the result at the wrong nesting level.

The fix adds a helper method createMissingParentRecords that walks the FieldValue parent chain and creates an empty MapRecord for each missing intermediate node, setting it on its parent before the actual value is applied. After creating the intermediate Records, incorporateInactiveFields is called so the new fields appear in the active schema and the re-evaluated path resolves them correctly.

This fix applies to both scalar lookup values and Record-typed lookup values.

Summary

NIFI-16002

Tracking

Please complete the following tracking steps prior to pull request creation.

Issue Tracking

Pull Request Tracking

  • Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
  • Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000
  • Pull request contains commits signed with a registered key indicating Verified status

Pull Request Formatting

  • Pull Request based on current revision of the main branch
  • Pull Request refers to a feature branch with one commit containing changes

Verification

Please indicate the verification steps performed prior to pull request creation.

Build

  • Build completed using ./mvnw clean install -P contrib-check
    • JDK 21
    • JDK 25

Licensing

  • New dependencies are compatible with the Apache License 2.0 according to the License Policy
  • New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

  • Documentation formatting appears as expected in rendered files

@rakesh-rsky
rakesh-rsky force-pushed the fix/NIFI-16002-lookuprecord-missing-parent branch from 9c05a4b to 6ee918b Compare June 12, 2026 16:14
…s missing

When the configured Result RecordPath contains intermediate nodes that do not yet
exist in the record (e.g. /enrichment/value where /enrichment is absent), the
RecordPath evaluator returns a missing-child FieldValue with a null value. When
updateValue is later called, getParentRecord() skips the null intermediate node and
finds the root record instead, writing the result at the wrong nesting level.

The fix adds a helper method createMissingParentRecords that walks the FieldValue
parent chain and creates an empty MapRecord for each missing intermediate node,
setting it on its parent before the actual value is applied. After creating the
intermediate Records, incorporateInactiveFields is called so the new fields appear
in the active schema and the re-evaluated path resolves them correctly.

This fix applies to both scalar lookup values and Record-typed lookup values.
@rakesh-rsky
rakesh-rsky force-pushed the fix/NIFI-16002-lookuprecord-missing-parent branch from 6ee918b to 53bd07d Compare July 22, 2026 06:43

@exceptionfactory exceptionfactory left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for proposing this approach to improve the behavior of LookupRecord @rakesh-rsky. On initial review, I'm not sure whether creating missing intermediate objects is the right approach. The primary concern is that it alters the functional schema of the Record, without reflecting those changes in the Record Schema.

The current behavior does seem problematic, ignoring the intermediate field, and it seems like throwing an error might be an option to consider. There also appears to be some potential performance implications of this approach. Another possibility is to configure this behavior through a new property, but it would be helpful to evaluate the potential issues before moving in that direction.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants